The present invention relates to computer programming, and in particular, to a service integration framework.
Services could be tradable similar to manufactured goods. Organizations dynamically interact as service consumers and service providers making use of a service marketplace to design, offer and consume services. Services (offered via the service marketplace) need to be integrated into standard business applications running within enterprise systems (e.g., ERP systems). These systems reflect the core business processes of an organization and can flexibly be enriched with complementary services.
Conventionally, the enterprise system is extended only with a service using a pre-defined service interface that has explicitly been foreseen by the enterprise system provider when the system was shipped. Examples are (de-facto) standard interfaces for Business-to-Business (B2B) or Application-to-Application (A2A) integration scenarios known from the area of Enterprise Application integration (EAI). Enterprises may desire an end-to-end service delivery scenario where services can be dynamically added as described above. However, the enterprise has to manually identify and adapt/extend the affected parts of the core business application(s) and manually integrate the service. This manual integration hinders the overall scalability of the service marketplace where multiple service providers and service consumers dynamically engage and interact.
Thus, enterprise systems only provide proprietary adaptation/extension techniques with a low level of abstraction. These techniques include many disadvantages. For example, a lot of manual effort (e.g., programming) is needed to extend the enterprise system with a new service. Different tools are needed during the integration process to perform various integration tasks, i.e., typically the overall set of integration tasks is not managed as a whole on a technical level within a single tool. Also, the high amount of needed integration skills and expertise needed limits the participation of non-experts in the integration because it is very difficult for the non-experts to plan and oversee all necessary or possible integration activities.
Also, the enterprise systems only provide proprietary (non-standardized) techniques for adaptation and extension with a low level of abstraction (e.g., proprietary code-level interfaces where additional integration code can be plugged in). Furthermore, in some cases the artifacts of the core enterprise system need to be directly changed with a negative impact on the software-lifecycle-management if no explicit extension techniques are provided. The usage of these low level adaptation and extension techniques to achieve the intended service integration is not explicitly modeled on a higher abstraction level. Typical integration activities that need to be carried out are typically provided in the form of best-practice recommendations to the experts, who then need to manually extend the core business application.
Also, the integration of unforeseen services may require the adaptation/extension of the core business application(s) on multiple application layers (e.g., on presentation- and/or business process layer). Typically, enterprise systems provide different adaptation/extension techniques on the different application layers, which requires deep knowledge of the different technologies.